• This hides the fact that the variable will change automatically, potentially causing confusion
• It may not always be intended that a (mutable) variable updates automatically, so this would make that case impossible

By doing this, Svelte will be changing a standard javascript behavior.

The migration from v3 may be kinda painful because devs will need to review all existing components to see if the reactive approach is intended, and if not, he won't be able to have a mutable non-reactive variable.

I think this change has little to add to compensate the tradeoff mentioned above.

No, it'll break a code pattern I've seen used in several different libraries.

<script>
    let value = ...;
    let oldValue = value;

    $: {
        // do something with value and oldValue
        oldValue = value;
    }
</script>

Your proposal breaks the assumption that oldValue won't suddenly change, which breaks any code that uses this pattern. Now, I'd love for Svelte to have an API to tap into the update and do stuff before the variable changes. However, when the API for that doesn't exist (which is now), that pattern works well enough, and your proposal will break it.